Communications systems evolve more and more towards an Internet Protocol (IP)-based network. They typically consist of many interconnected networks, in which speech and data is transmitted from one terminal to another terminal in pieces, so-called packets. IP packets are routed to the destination by routers in a connection-less manner. Therefore, packets comprise IP header and payload information, and the header comprises, amongst other things, a source and destination IP address.
For scalability reasons, an IP network uses a hierarchical addressing scheme. Hence, an IP address does not only identify the corresponding terminal, but additionally contains location information about this terminal. With additional information provided by routing protocols, routers in the network are able to identify the next router towards a specific destination.
Tunneling is a mechanism that is used for transmitting data packets as a payload of another data packet, i.e. for transporting a data packet encapsulated by another protocol of the same particular OSI layer. A logical construct called a tunnel is established between the device that encapsulates and the device that decapsulates, wherein the process itself is referred to as tunneling. The tunneling may be used for transmitting data packets over networks that support different network protocols, e.g. an IPv6 packet needs to be encapsulated in an IPv4 packet for transport over an IPv4 network. Tunneling may also be used to provide a secure transport of data over a network that is considered as insecure. For instance, the IP security Protocol (IPsec) can be used to tunnel a data between authenticated entities transparently for the underlying networks that connect both entities.
Usually, when a terminal powers on, it configures an IP address that is based on the IP address prefix of the access network. If a terminal is mobile (so-called mobile node, MN) and moves between subnets with different IP prefix addresses, it must change its IP address to a topological correct address due to the hierarchical IP addressing scheme. However, since transport layer connections, such as TCP connections are bound to the IP addresses (and ports) of the communicating nodes, the connection to the active IP sessions breaks if one of the nodes changes its IP address, e.g. due to movement. One possible protocol to address said problem is the MIPv6 protocol.
Mobile IPv6 (MIPv6)
Mobile IPv6—also denoted as MIPv6—(see D. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6”, IETF RFC 3775, June 2004, available at http://www.ietf.org and incorporated herein by reference) is an IP-based mobility protocol that enables mobile nodes to move between subnets in a manner transparent for higher layers and applications, i.e. without breaking higher-layer connections. That is, the mobile nodes remain reachable while moving around in the IPv6 internet network. The main principle of MIPv6 is that a mobile node is always identified by its Home Address (HoA), regardless of its topological location in the internet, while a Care-of Address (CoA) of the mobile node provides information about the current topological location of the mobile node. The MIPv6 protocol is usually used in non-3GPP networks.
In more detail, a mobile node has two IP addresses configured: a Care-of Address and a Home Address. The mobile node's higher layers use the Home Address for communication with the communication partner (destination terminal), from now on called Correspondent Node (CN). This address does not change and serves the purpose of identification of the mobile node. Topologically, it belongs to the Home Network (HN) of the mobile node. In contrast, the Care-of Address changes on every movement that results in a subnet change and is used as the locator for the routing infrastructure. Topologically, it belongs to the network the mobile node is currently visiting. One out of a set of Home Agents (HA) located on the home link maintains a mapping of the mobile node's Care-of Address to mobile node's Home Address and redirects incoming traffic for the mobile node to its current location. Reasons for deploying a set of home agents instead of a single home agent may be redundancy and load balancing.
Mobile IPv6 currently defines two modes of operation: bi-directional tunneling (FIG. 1) and route optimization (FIG. 2). Using bi-directional tunneling, data packets sent by the correspondent node 101 and addressed to the home address of the mobile node 102 are intercepted by the home agent 111 in the home network 110 and tunneled to the Care-of address of the mobile node 102, which is anchored at the foreign network 120. Data packets sent by the mobile node 102 are reverse tunneled to the home agent 111, which decapsulates the packets and sends them to the correspondent node 101. Reverse tunneling means that packets are transmitted by the mobile node via an additional reverse tunnel (to complement the “normal” one) that starts at the mobile node and terminates at the home agent.
For this operation in MIPv6, only the Home Agent 111 is informed about the Care-of Address of the mobile node 102. Therefore, the mobile node sends Binding Update (BU) messages to the Home Agent. These messages are sent over an IPsec security association, and thus are authenticated and integrity protected.
A drawback is that if the mobile node is far away from the home network and the correspondent node is close to the mobile node, the communication path is unnecessarily long, resulting in inefficient routing and high packet delays.
In order for the MN to have an IPsec association with the HA, the MN needs to perform bootstrapping a-priori. Bootstrapping is the process of obtaining at least the following information: a home address, a home agent address, and a security association with home agent. This information is needed before the MN registers a CoA with the home agent. The process may last several seconds because several round-trip-times between MN and HA are needed.
The route optimization mode (see FIG. 2) can prevent the inefficiency of the bi-directional tunneling mode by utilizing the direct path between correspondent node and mobile node. RO requires the MN to register its current binding of the home address to care-of-address at the CN. Correspondingly, the CN establishes a binding cache entry, so that packets from the CN can be routed directly to the CoA of the MN, without the detour over the HA of the MN1. When sending a packet to any IPv6 destination, the CN checks its cached bindings for an entry of the packet's destination address.
When using route optimization, the mobile node sends binding update messages to the correspondent node to support mobility, which then is able to directly send data packets to the mobile node (a type 2 routing header is used to send the packets destined to the mobile node's home address on the direct path to the mobile node's care-of address).
The protection of Binding Updates sent to correspondent nodes does not require the configuration of security associations or the existence of an authentication infrastructure between the mobile nodes and correspondent nodes. Instead, a method called the Return Routability (RR) procedure is used to assure that the right mobile node is sending the message.
The Return Routability procedure enables the correspondent node to obtain some reasonable assurance that the mobile node is in fact addressable at its claimed Care-of address as well as at its Home address. Only with this assurance is the correspondent node able to accept Binding Updates from the mobile node which would then instruct the correspondent node to direct that mobile node's data traffic to its claimed Care-of address.
This is done by testing whether packets addressed to the two claimed addresses are routed to the mobile node. The mobile node can pass the test only if it is able to supply proof that it received certain data (the “keygen tokens”) which the correspondent node sends to those addresses. The exchange of the cryptographic tokens is based on the HoTi/HoT and CoTi/CoT message exchanged. These data are combined by the mobile node into a binding management key. The integrity and authenticity of the Binding Updates messages to correspondent nodes is protected by using the binding management key.
Thus, MIPv6 allows to optimize the route between the CN and the MN by allowing a mapping in the CN of the HoA and CoA of the MN, so that the CN can communicate directly with the MN.
A mobile node may have several home agents and thus may establish several security associations for the corresponding IPsec tunnels, one to each home agent. For each home agent, the mobile node configures a different home address, which is used for communication. Thus, depending on the source address of the data packet, the data packet is transmitted over the appropriate IPsec tunnel to the corresponding home agent. Mobile IP is categorized as host-based (or client-based) mobility management, since the mobility-related signalling is between the host (or client) and the HA. Hence, it is sometimes called Client Mobile IP (CMIP).
Proxy MIPv6 (PMIPv6)
Another approach, targeting the IP mobility management in limited geographical regions, is managed by the network and therefore is transparent to the MN. This approach is referred to as network-based, localized IP mobility.
One main characteristic of network-based mobility is that the access network entities are appropriately configured to detect the MN movement and to exchange information about the current location of the MN, so that the MN does not need to be involved in the mobility process. Therefore, the mobility-related signaling over the wireless interface is avoided. Other advantages of the network-based mobility management are less packet overhead over the air, since no MIPv6 encapsulation is needed, and mobility support for simple IP nodes (i.e., non-MIP-capable nodes). The Internet Engineering Task Force (IETF) organisation is working on such an approach for localized mobility management based on the Mobile IP protocol. Since a network entity is acting as a proxy on behalf of the MN, the protocol is called Proxy Mobile IP (PMIP). There is a variant for IPv6 called PMIPv6 and a variant for IPv4 called PMIPv4. Most of the embodiments of this invention assume PMIPv6 as protocol for network-based mobility management, but the invention is not limited to PMIPv6. It may also be applicable to other network-based mobility management protocols such as PMIPv4.
To provide mobility support to any IPv6 host within a restricted and topologically localized portion of the network and without requiring the participation of the host, proxy mobile IP (PMIP) introduces a new logical entity called Mobile Access Gateway (MAG) which is the proxy mobility agent in the MN's network which manages the mobility related signaling for a mobile node that is attached to its access link. It is the entity responsible for tracking the mobile node's attachment to the link and for signaling the mobile node's local mobility anchor. The MAG is usually co-located with the access router (AR) and performs Mobile IPv6 signaling on behalf of the mobile node, e.g. can send BU messages on behalf of a MN. These BU messages are marked with a flag, so that they can be identified as Proxy BU (PBU) messages.
A Local Mobility Anchor (LMA) is the home agent for the mobile node in the Proxy Mobile IPv6 domain. It is the topological anchor point for the mobile node's home prefix and is the entity that manages the mobile node's reachability state. It is important to understand that the LMA has the functional capabilities of a home agent as defined in the Mobile IPv6 base specification and with the additional required capabilities for supporting Proxy Mobile IPv6. Usually one LMA is connected to multiple MAGs by means of secure IPsec tunnels.
When using PMIPv6, a Home Network Prefix is allocated to the mobile node by the LMA. The mobile node can then configure an IP address based, say home address, on that prefix. Said home address is used for all communication sessions and does not change while the mobile node remains in the current PMIP domain. A correspondent node in communication with the mobile node transmits data packets destined to the home address of the mobile node. The home address has the IP prefix of the LMA; thus, the data packets are routed to the LMA, that in turn tunnels the data packets over the PMIP tunnel to the MAG. The MAG decapsulates these data packets and knows from a corresponding routing entry that data packets destined to the home address of the mobile node are to be forwarded to the mobile node, though the IP prefix of said home address is allocated at the LMA.
IPsec Protocol and the Security Associations
Generally, IPsec provides security services at the IP layer for higher-layer protocols and applications in order for them to communicate securely. That is, IPsec sets up a secure path between two communicating nodes over insecure intermediate systems. In this respect, IPsec is composed of several components to provide security service, wherein the two main ones are the Authentication Header (AH) protocol and the Encapsulating Security Payload (ESP) protocol. They provide authenticity and privacy to IP data by adding particular headers to the IP data packet.
There exist two modes of IPsec operation. On the one hand the transport mode operation and on the other hand the tunnel mode operation. In transport mode, only the payload of the data packet is encrypted. It is fully routable since the IP header is sent as plain text. In tunnel mode, the entire IP packet is encrypted. It must then be encapsulated into a new IP packet for the routing process. Tunnel mode is used for network-to-network communications, i.e. for setting up secure tunnels between routers.
IPsec is used for instance between a mobile node and its home agent. In order for a mobile node to have an IPsec security association with the HA, the MN needs to perform bootstrapping a-priori. Thus, even if the mobile node is attached to a foreign network, encrypted and/or authenticated/authorized communication between the home agent and the mobile node (e.g. through a secured tunnel) may be ensured.
IKEv2 is used for performing mutual authentication, as well as establishing and maintaining IPsec Security Associations (SAs). In the base IKEv2 protocol, the IKE SAs and tunnel mode IPsec SAs are created implicitly between the IP addresses that are used when the IKE_SA is established. The IKE_SA is used to negotiate shared keys between the communication partners. These shared keys are then used in the negotiation for the IPsec SA. Furthermore, the IPsec SA defines the communication partners, and which packets are to be transmitted to which IP address, and the encryption used for the transmission of said packets etc. These IP addresses are then used as the outer (tunnel header) addresses for tunnel mode IPsec packets.
As apparent from above, the IPsec tunnel based on the security association is typically established between the addresses of the endpoints, e.g. to the home agent address and one of the mobile node's addresses e.g. the care-of address in case of MIPv6. On the other side, the home address of the mobile node is used as identifier of the security association or as identifier of the IPsec (or MIP) tunnel. Usually the home address is assigned by the home agent and it is derived from the address space of the home agent, i.e. the home address is topologically correct in the home agent.
LTE—Long Term Evolution
The 3GPP (3rd Generation Partnership Project) launched a study item “Evolved UTRA and UTRAN” better known as “Long Term Evolution (LTE)”. The study will investigate means of achieving major leaps in performance in order to improve service provisioning, and to reduce user and operator costs. Out of that and because interworking with other radio access technologies should be possible, the need arose for a new evolved Packet Core Network.
An exemplary representation of the E-UTRAN architecture is given in FIG. 3. The E-UTRAN consists of evolved Node Bs (eNB or eNodeB), providing the E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards the mobile node.
The eNB hosts the Physical (PHY), Medium Access Control (MAC), Radio Link Control (RLC), and Packet Data Control Protocol (PDCP) layers that include the functionality of user-plane header-compression and encryption. It also offers Radio Resource Control (RRC) functionality corresponding to the control plane. Further, it performs many functions including radio resource management, admission control, scheduling, enforcement of negotiated UL-QoS (Uplink Quality of Service), cell information broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of DL/UL (Downlink/Uplink) user plane packet headers. The eNBs are connected to the Serving Gateway (S-GW) by means of the S1-U interface.
The S-GW routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between 2G/3G systems and Packet Data Network Gateway). For idle state UEs, the S-GW terminates the DL data path and triggers paging when DL data arrives for the UE. It manages and stores UE contexts, e.g. parameters of the IP bearer service, network internal routing information. It also performs replication of the user traffic in case of lawful interception.
The Mobility Management Entity (MME) is an entity from the Evolved Packet Core Network of a 3GPP cellular network that is responsible for the mobility management and session management of the MN. The mobility management is handled in both MN states: connected (when the MN is connected to an (e)NB), i.e. RRC connection and Radio Bearers between the MN and (e)NB are established) or IDLE (when the MN is registered at the PLMN (public land mobile network) but not connected to a particular (e)NB). The MME manages the discovery of the PGW and SGW for the MN and the tunnel establishment between the (e)NB and the SGW/PGW. The MME is connected to an eNB via the S1-MME interface that applies the S1-AP (Application) protocol for message exchange. Further, the MME is connected to the SGW via the S11 interface.
The Packet Data Network Gateway (PDN-GW or PGW) provides connectivity for the UE to external packet data networks by being the point of exit and entry of traffic for the UE. A UE may have simultaneous connectivity with more than one PDN-GW for accessing multiple PDNs. The PDN-GW performs MN IP address allocation, policy enforcement, packet filtering (e.g. deep packet inspection, packet screening) for each user in order to map the MN's traffic to an appropriate QoS level. The PGW performs the function management of a HA in case of MIPv6 and of LMA in case PMIPv6 protocols are used for mobility. The PGW is connected to the SGW via the S5 interface, if the SGW is located in the same PLMN, or via the S8 interface if the SGW is located in a foreign (visited) PLMN.
Another key role of the PDN-GW is to act as the anchor for mobility between 3GPP and non-3GPP technologies. The 3GPP LTE system differentiates between 3GPP and non-3GPP access networks. The 3GPP access networks are based on access technologies standardized by the 3GPP organization. The MN mobility within the 3GPP access networks is usually managed by network-based mechanisms, e.g. PMIPv6 as described above. The non-3GPP access networks are based on access technologies defined by other organizations like Institute of Electrical and Electronics Engineers (IEEE) and 3rd Generation Partnership Project 2 (3GPP2). The MN mobility within the non-3GPP access networks can be managed either by host-based mobility mechanism (e.g. MIPv6) or network-based mechanisms (e.g. PMIPv6).
When the mobile terminal is active in a non-3GPP access network, there is a local IP address used to route packets to the mobile terminal in the non-3GPP access. This IP address is the Care-of Address in the terminology of Mobile IP. In case of DSMIPv6, the address is assigned to the mobile terminal, and the mobile terminal is sending Binding Updates using its Care-of address to the PDN-GW, which has the function of the Home Agent (HA). In case of PMIPv6, the Care-of address is an address of a Mobile Access Gateway (MAG) that is located in the non-3GPP access network, and the MAG is sending Proxy Binding Updates using its (Proxy-) Care-of Address to the PDN-GW of the 3GPP network, which has the function of the Local Mobility Anchor (LMA). However, the MN has only one address in PMIP, namely the IP address allocates at the LMA.
Public Land Mobile Networks
A public land mobile network (PLMN) is a network that is established and operated by an administration or by a recognized operating agency for providing land mobile telecommunications services. PLMNs interconnect with other PLMNs and Public switched telephone networks (PSTN) for telephone communications or with internet service providers for data and internet access. A PLMN may be considered as an extension of a fixed network, e.g. the Public Switched Telephone Network (PSTN) or as an integral part of the PSTN. This is just one view-point on PLMN. PLMN mostly refers to the whole system of hardware and software which enables wireless communication, irrespective of the service area or service provider. A separate PLMN may be defined for each country or for each service provider.
Every PLMN organisation has its own management infrastructure, which performs different functions depending on the role played and the equipment used by that entity. However, the core management architecture of the PLMN organisation is similar, such as:                providing services to its customers;        infrastructure to fulfill the services (advertise, ordering, creation, provisioning, . . . );        assuring the services (Operation, Quality of Service, Trouble Reporting & Fixing . . . );        billing the services (Rating, Discounting, . . . ).        
Not every PLMN organisation will implement the complete Management Architecture and related processes. Some processes may be missing depending on the role a particular organisation is embodying. Processes not implemented by a particular organisation are accessed via interconnections to other organisations, which have implemented these processes. The Management architecture itself does not distinguish between external and internal interfaces.
A MN subscribed to 3GPP services has a home PLMN (HPLMN) that maintains the subscription data and allowed services and QoS levels. When MN is attached to a network different from the HPLMN, the MN is indicated as roaming node and the visited network is denoted as visited PLMN (VPLMN).
In general, “roaming” can be defined as the ability for a cellular customer to automatically make and receive voice calls, send and receive data, or access other services, including home data services, when travelling outside the geographical coverage area of the home network, by means of using a visited network.
The differentiation between HPLMN and VPLMN is technically given by the type of subscriber entry in a specific network. When a mobile device enters a new visited network and has no entry in the home subscriber register of the network (e.g. Home Location Register, HLR, in GSM networks or local customer database in WLANs), the required subscriber data must first be requested by the visited network e.g. from the subscriber's home network in order that the subscriber can be authenticated and any authorization for using the network services can be checked. The “visiting” subscriber acquires an entry in a user database of the visited network (e.g. Visited Location Register, VLR) and the authorized network services are enabled. If there is no roaming agreement between the two networks, i.e. HPLMN and VPLMN, maintenance of service is impossible, and service is denied by the visited network.
Home (e)NodeB, Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO)
The usual term used for a base station in the 3GPP specifications is node B (NB, for the UMTS radio access network) or evolved node B (eNB, for the LTE radio access network). The area of coverage of an NB/eNB is called NB/eNB cell or a macro cell. In the recent evolution 3GPP specified base stations called Home (e)NodeB (abbreviated as H(e)NB) that could be deployed by private organisations or enterprise networks. These H(e)NBs could be connected to the operator's core network via DSL or other secure fixed-line connection.
A H(e)NB provides services only to limited users allowed to associate with the H(e)NB. This service offered by the H(e)NB access is known as Closed Subscriber Group (CSG) service. This introduces a main difference to the usual (e)NB macro cell where all users can attach to an (e)NB if they are allowed to attach to the PLMN, to which the (e)NB is connected.
A further new feature in the cellular networks is the ability of the radio access network to route the MN's IP traffic directly to the Internet (or to the correspondent node) without traversing the operator's core network. This new feature can be applied when the MN is attached to either a usual macro (e)NB cell or to a micro H(e)NB cell. In 3GPP, Local IP access (LIPA) and Selected IP traffic offload (SIPTO) are defined when the MN's IP traffic is directly routed without traversing the core network.
In case the MN is attached to a usual macro (e)NB cell the 3GPP specification talks about SIPTO. Usually the term LIPA is used in case of MN-initiated local IP traffic routing when the UE is attached to a micro H(e)NB cell of a residential or enterprise IP network. On the other hand the term SIPTO is used when the network-side decides to perform local IP traffic routing when the MN is attached to micro H(e)NB cell or to macro (e)NB cell.
In order to perform a LIPA or SIPTO it is assumed that a local gateway (called herewith L-PGW) is used. The MN's traffic goes via the L-PGW to the destination IP network or correspondent node. The L-PGW can be located in the access network or above the access network; however, it is important that the L-PGW is located in such a way that the core network is offloaded.
In some aspects the LIPA/SIPTO local forwarding has a similar concept as the Local Break-Out (LBO) known from the roaming scenario, where also a local (visited) PGW in the visited PLMN (VPLMN) is deployed. One main difference between LIPA/SIPTO and LBO is that LBO is a term used only for roaming mobile nodes in visited PLMNs, whereas the LIPA/SIPTO is a local routing within or above the access network of one PLMN. A further main difference is that the PGW in case of LBO is located in the Core network, whereas the local PGW in case of LIPA/SIPTO is usually located in the access network (RAN) or close to the access network; and in case of LIPA—in the residential/enterprise IP network. With other words, LBO can be observed as offloading merely the HPLMN's core network, but the MN's traffic still traverses the VPLMN's core network.
Route Optimizations
Because of an increasing demand for real-time IP based applications and a need for handling vast volumes of user traffic, an efficient packet routing is becoming more and more important. The end-to-end latency of user traffic should be minimized, for instance, to satisfy the requirements of interactive applications.
FIG. 4 shows an exemplary scenario in which two mobile nodes, MN1 and MN2, are communicating with each other, wherein both MNs are in the same VPLMN. However, the data traffic is transmitted via the home agents of the MNs, i.e. over MN1's HA, PGW1, in HPLMN1 and over MN2's HA, PGW2, in HPLMN2. This is illustrated with the continuous bold line. For this scenario it is assumed that MN1 uses MIPv6 for mobility management, and MN2 uses PMIPv6. Therefore, an MIPv6 tunnel spans from MN1 over the VPLMN to PGW1. In 3GPP the MIPv6 interface is called S2c interface. Similarly, a PMIPv6 tunnel goes from the Serving Gateway, being the MN2's MAG, to PGW2, being the MN2's LMA.
For instance, the HPLMNs of MN1 and MN2 may be located in one continent (Europe), and both nodes are currently roaming to another continent (USA). In this case, the data packets exchanged between the two nodes are traversing a very long distance, resulting in long delays and inefficient routing.
As already mentioned with reference to FIG. 2, MIPv6 provides a mechanism for route optimization. Since MN1 is using MIPv6, it can perform the RR/RO for MIPv6. The thus optimized route is illustrated in FIG. 5. However, since MN2 is not at its HPLMN, the completion of MIPv6 RO procedure would result in merely avoiding the data traffic to flow through the HPLMN1, but still the traffic flows from VPLMN (USA) to HPLMN2 (Europe) and back to the VPLMN (USA). As apparent therefrom, the data route is not optimal and still has long delays and inefficient routing.
In addition, MN2 needs to participate in the MIPv6 route optimization, and thus needs to support MIPv6. It should also be noted that MN2 cannot perform MIPv6 RO to avoid the detour over its HA in HPLMN2, since MN2 already uses PMIPv6 for mobility management. Therefore, to have an optimal route it is necessary that MN2 is able to use MIPv6 to also perform the RR/RO procedure in the other direction.
In case that the mobile node is attached to a visited network (PLMNs) two modes of operation are possible with respect to the data traffic forwarding—home-routed traffic and local break-out. The home-routed traffic means that the MN gets the IP configuration from its HPLMN, and all the traffic is always routed between MN and HPLMN over the VPLMN. The home-routed traffic mode is implemented by establishing a PMIP tunnel between the VPLMN and HPLMN (indicated as S8 interface above). In case of LBO, the MN gets the IP configuration from the VPLMN, and the data traffic is not routed to the HPLMN, but from the MN over the VPLMN to the correspondent node directly. The operation mode is initiated by the MN, as during the attach procedure, the MN requests for a connection (also called PDN connection) to a particular Access Point Name. If the PGW of the requested APN is located in the HPLM, the MN's PDN connection is called home-routed. If the PGW corresponding to the requested APN is located in the VPLMN, the MN's PDN connection is denoted LBO.
In case MN1 uses LBO, the optimized data route is depicted in FIG. 5, which is practically the same as for MIPv6 RO performed by MN1. Again, the route is not the optimal one.
In addition, MN2 may also use the LBO mode of operation, which would indeed result in the optimal data route illustrated in FIG. 4 with the dashed line. Both nodes would establish new PDN connections to new PGWs located in the VPLMN. For example, if the AGW is located in the VPLMN's core network and offers corresponding PGW functionality, MN1 can use it as local PGW for LBO. Analogically, if the SGW offers the PGW functionality, MN2 can use it as local PGW in the VPLMN for LBO.
However, the LBO operation has serious disadvantages.
For instance, the establishment of connections to new local PGWs must be completed before the data communication starts, because the mobile nodes would configure new IP addresses that are topologically correct in the VPLMN and those IP addresses are used for communication between the mobile nodes. Therefore, already established sessions using the home address of MN2 will be interrupted due to said IP address change. Consequently, it is necessary to perform the LBO before the data communication starts, which requires synchronization between the mobile nodes and even coordination between the HPLMNs. Further, the LBO set-up is a time and signalling consuming process. It would be advantageous to have a route optimization that can be performed at any time during or before the actual communication.
One example to perform synchronization between the mobile nodes to set up the LBO before the beginning of data communication is to use higher layer protocols, such as application layer protocol e.g. Session Initiation Protocol (SIP). The synchronization of the application layer protocols and the network layer protocols would require special implementation mechanisms in both mobile nodes, which results in lack of backwards compatibility. Also, another disadvantage of using application layer signalling is that the RO path can be set up only for those kinds of applications, for which the application layer signalling is needed, e.g. only SIP-based applications.
Furthermore, a route optimization with reduced signalling load and delay for the set up of the route optimized path would be beneficial.